1. Field of the Invention:
The present invention relates to the art of software development for digital computing, and more particularly to the arts of (1) debugging and optimizing higher level language programs, and (2) testing procedures for higher level language programs.
2. Description of the Prior Art:
In the past, after computer programs are created, programmers must debug the program. Such programs are usually created out of many procedures and subroutines, each of which is a series of lines of source code intended to perform some specific task or function. "Subroutines," "functions" and "procedures" are self-contained segments of the program, comprising a group of source code lines that perform a specific function. Hereinafter in this specification, the term "source line" may be used from time to time as the same as and synonymous with the term "source code line" for ease and clarity in understanding and description.
Initially, a computer performs its tasks by "executing" machine code. Machine code is a series of machine instructions. Each instruction usually consists of a coded sequence of binary bits comprising a series of positives and negatives, ones and zeros or similar type of two level information. A digital processing apparatus responds to such machine instructions by operating upon other machine coded data stored in a memory, according to the program. A set of such machine instructions is loaded into a central processing unit of the digital processing apparatus, or computer from a memory called a machine instructions file. The memory device for both could be a disk, floppy disk, tape, read only memory (ROM), flash memory or the like. Thus, the central processing unit of the computer retrieves an initial machine instruction from the memory and carries out the tasks specified by the instruction. In carrying out or performing the specified tasks of the machine instruction, the computer is said to "execute" the machine instruction.
A machine instruction will not only operate upon the data in memory in accordance with the program, but will also instruct the central processing unit as to which machine instruction to retrieve and execute next. This process of executing one machine instruction after the next may continue indefinitely or until a machine instruction is executed that instructs the central processing unit to stop the execution process. Some digital processing apparatuses include improvements to speed up computer programs by allowing the computer to execute several machine instructions at once if it can do so, while still generally appearing to behave as if it is executing one at a time in sequence. Generally, such improvements do not change the fundamental sequential nature of the computer's execution process.
Machine code instructions can be represented in alpha-numeric expressions for display on display devices. Typically, moreover, computer manufacturers create a more human readable version of their machine code, called "assembly code" having its own "assembly language." The computer translates the assembly language into machine instructions for execution of the program. Assembly language makes it a somewhat easier task to program. However, such assembly languages are usually unique to that manufacturer's computers, and to make a program executable on another computer, the entire program must be rewritten in another's assembly language.
As a consequence, higher, or "high" level programming languages have been developed which are designed to run on all brands of computers. Using such higher level programs, a computer programmer can express general mathematical formulae and complex data relationships in a way that is independent of the actual brand of computer on which the program will be run. The computer programmer need not know what machine code language instructions will actually be used to implement his mathematical formulae. In this manner, the programmer can concentrate on the general specification of the algorithm without having to figure all of the detailed machine instructions necessary to carry out or execute his tasks. Among the more popular higher level programming languages are C, Fortran, Cobol, C++, Ada, Pascal and Lisp.
The indicia used to identify these higher level programming languages bear a resemblance to ordinary, written languages. Such indicia are usually written in alpha-numeric symbols, including various punctuation marks and characters, in a line from left to right. A single command created by a programmer in such a higher level language usually comprises a single line, but in any event is called a "source code line" or, more simply, a "source line." It is a series of such source lines of code that comprise the subroutines, functions and procedures that, collectively, will in turn comprise a complete program. Each of such subroutines, functions or procedures is itself a self-contained segment of the program, and each comprises a group of source code lines, source lines or instructions that performs a specific function or task. Such source lines are stored in a memory, called a source lines file. These source lines are stored in the source lines file in an order which, for purposes of this description, will be called the source order or, sometimes, the source code order. The alpha-numeric expressions or indicia representing each of such source lines can be displayed on a display device, and are usually presented in a column from top to bottom in the order in which the source code line or command is to be carried out in the fundamental sequence of the computer's run of the program. Generally, this order is coincidental with the source order.
Displays are usually provided which present the results of the computer's operations to the user. The display can take the form of a permanent medium, such as printed paper where the results of the computer are printed by a printer, as well as such media as magnetic implanted or recorded tapes, data disks and like devices which can be either human readable or understandable or machine readable. The display can be in the form of a transient medium, such a video terminal or screen. Video screens can be the usual cathode ray tube screen as well as liquid crystal displays, virtual reality displays, holographic displays and so on. Further, such displays are used not only to present the results of the computer's operation, but also to present various information from or through the computer, such as, for example, the data stored within the computer's memory, such as the machine code instructions, source lines file, diagnostic programs and other information kept in the computer's memory or in the memory of peripheral equipment attached to the computer. Hereinafter in this description, the term "display" shall be used and is intended to mean all of such display devices, as well as other media through or on which the results and other information from or through a computer can be presented to a user or another machine.
Most such digital processing apparatuses have some way of inserting codes, data and instructions into the computer. Such input devices include keyboards and/or some form of pointing devices. Pointing devices can be a light pen, a graphics tablet, arrow keys on a keyboard, a track ball or the "mouse" or "clicker" for positioning a pointer or cursor on the display screen or other output presentation.
"Interactive display" or "interactive display device" are terms that are sometimes used to refer to those displays that combine computer input and output functions. These devices allow the user to identify a location on the display so that the digital processing apparatus can then respond to that location identification as a command or instruction for further action or operation. Such a combination could be, for example, a video screen (cathode ray tube) and a pointing device, such as a "mouse" that moves a screen visible arrow or like cursor to identify a location among the indicia showing on the screen. Stylus sensitive liquid crystal display panels are another example of such an interactive display.
Another combination might be the screen display and a finger of the user's hand, where the screen display is sensitive to the finger's touch, and responds to that touch as if it were a command. Heads up displays, virtual reality displays and the like are additional such interactive displays.
The speed and reliability advantages afforded by higher level program languages cause most programs to be written in higher level languages. Many subroutines, functions and procedures can be very long, often containing hundreds and sometimes thousands of source lines. Furthermore, since the variations and permutations of possible functioning of these subroutines and functions is very large, it is impractical for the programmer to put the program through all possible tests, even assuming that he could know them all.
Instead, it is general practice to give a new program, after the programmer has performed rudimentary testing, to a number of testers who will exercise the program and all of its subroutines and functions more thoroughly in a variety of environments, applications, iterations and combinations. Typically, such testers identify those tasks and operations which the program cannot perform in the manner in which the tester has tried. In such testing, the tester usually identifies only those subroutines or functions which fail to perform their specific task assigned within the overall scheme of the program. Such testers normally are unable to thoroughly test all possible source code lines, many of which may malfunction under the circumstances which call for their use.
At the end of the testing, lists of these "bugs" are submitted to the programmer. The programmer can then make corrections to, or debug the program in light of the testers'feedback, and re-submit the debugged program to the testers for further testing. Sometimes, this process is repeated several times until an acceptably well functioning version of the program is achieved.
Generally, testers are unconcerned with the time that a subroutine or function takes in the run of the program. Programmers, however, have at least two circumstances in which the amount of time that it takes to execute the program can be important. The first circumstance is when a malfunction of a subroutine, function or procedure is identified that results in it accomplishing its assigned tasks too slowly so that the results of that subroutine, function or procedure are untimely for fitting into the remaining part of the program, which may depend on those results for performing the overall task. A second circumstance occurs when the subroutine or function performance time is too slow by comparison with alternative or competing products.
In the first circumstance, the program cannot be released until the problem is resolved. The subroutine, function or its component loop must be made faster or optimized, that is re-written. In the second circumstance, the program may be released, but its acceptance and use will likely be limited accordingly.
Where a subroutine, function or procedure, and likely the entire program malfunctions because some part of a subroutine or function is too slow for its assigned task in the scheme of the program, the subroutine, function or procedure must be made faster. Typically, programmers look to alternative subroutines and functions which are faster for substitution into the program.
Even after the program has been debugged and the problems fixed so that the program works correctly, it is often found that the program does not carry out its tasks at the speed desired. A user may complain that the program carries out its tasks too slowly, or that it takes too long to perform some of its tasks. Programs are sometimes written to take advantage of certain features of one make of computer. Although the program will run on most other makes of computers because it is written in a higher level language, the other makes of computers in many instances will run that particular program slower than on the make for which it was originally written. A user having a program that runs too slowly on his particular computer may desire greater speed in order that his computer may handle more programs, or handle more tasks.
One solution to this problem of time or speed is to acquire a new computer on which the program will be run at a greater speed. This solution, however, can be costly.
In the past, certain performance analysis hardware and software have been provided that give the amount of time used by the most often executed machine instructions. The higher level language programmer, however, usually does not know the machine instructions into which his source lines are translated. Most programmers are not helped, therefore, by knowing how much time was used by any one individual machine instruction.
Further, it has been known to provide hardware and software that identify those segments of the program, such as subroutines, functions and procedures that use the most time. However, as noted, such functions, subroutines and procedures often consist of hundreds, even thousands of lines of source code. Such hardware and software do not identify which of these source lines use the most time when their corresponding machine code instructions are executed.
It is an object of the present invention to identify source code lines for which the time of use, or the amount of time spent to execute the machine code instructions into which the source lines have been translated, is the most. It is a further object of the present invention to provide and display the amount of time spent in the execution of the machine instructions for their corresponding source code lines. It is another object of the present invention to identify the source lines that are used repeatedly. It is yet another object of the present invention to provide a method and apparatus which can make these identifications displayed to the programmer in order according to the amounts of time so spent. It is yet a further object of the present invention to provide a method and apparatus which can present these identifications to the programmer in the source order provided by the source line file and in the likely order of sequential performance.
Testing procedures are frequently provided for testing a program, function or sub-routine. Such testing procedures often include running a program by or with test input and analyzing the results. However, many such testing procedures do not test all of the source code's lines. Indeed, frequently it is not known whether all of the source lines are used in a testing procedure. Therefore, the tester cannot verify whether every source code line is satisfactory. Worse, a program tester may develop an invalid belief in the operability of every code line in every application for which the program was designed.
It is another object of this invention to provide testers with a procedure for more easily ascertaining the completeness of a testing procedure, and to provide methods and apparatus for correcting deficiencies found.